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Abstract — In the literature, the definition of product in a 
Software Product Line (SPL) is based upon the notion of 
consistency of the constraints, imposed by variability and 
traceability relations on the elements of the SPL. In this 
paper, we contend that consistency does not model the natural 
semantics of the implementability relation between problem 
and solution spaces correctly. Therefore, we define when a 
feature can be derived from a set of components . Using this, we 
define a product of the SPL by a (specification, architecture) 
pair, where all the features in the specification are derived from 
the components in the architecture. This notion of derivability 
is formulated in a simple yet expressive, abstract model of a 
productline with traceability relation. We then define a set of 
SPL analysis problems and show that these problems can be 
encoded as Quantified Boolean Formulas. Then, QSAT solvers 
like QUBE can be used to solve the analysis problems. We 
illustrate the methodology on a small fragment of a realistic 
productline. 

Keywords -Software Product Line; Sanity analysis; Formal 
methods; QSAT 

I. Introduction 

Software Product Line (SPL) is a development framework 
to jointly design a family of closely related software products 
in an efficient and cost-effective manner. Every SPL is 
built upon a collection of features and components. Each 
individual product is specified by a subset of features 

Each product in the family is specified by a set of features 
drawn from a collection common to the family, and is 
implemented by an architecture comprising a set of reusable 
components selected from a collection of basic assets which 
are developed once for the entire family. 

There are two key orthogonal aspects of an SPL, namely, 
variability and traceability. While variability introduces dif- 
ferent choices (termed variation points) within the artifacts 
in system development, such as specifications, architectures 
and components, traceability relates the variation points 
together across the artifacts. Since variability introduces 
complex constraints among the variation points, managing 
variability in large industrial SPLs is quite complex and 
has given rise to a number of analysis problems. These 
have been the focus of SPL research in the recent years. A 
comprehensive survey of these analysis problems and their 
solutions can be found in Benavides et aLffl. 



On the other hand, we observe that traceability and 
its implications have not been studied in as much depth 
in the literature. In the following, we mention the few 
works addressing traceability as a primary aspect. It is 
defined in as one of the four important characteristics 
of a variability model, namely, consistency, visualization, 
scalability and traceability. A variability management model 
that focuses on the traceability aspect between the notion of 
problem and solution spaces is presented in (3J. Anquetil 
et al.|4| formalize the traceability relations across problem 
and solution space and also across domain and product 
engineering. In 0, the notion of product maps is defined 
which is a matrix giving the relation between features and 
products. Consistency analysis of product maps is presented 
in J6). Zhu et al.JT] define a traceability relation from 
requirement to feature and also from feature to architecture 
with consistency analysis. [8] presents a consistency verifica- 
tion method between feature model and architecture model. 
Metzger et al.[9| differentiate SPL variability and product 
variability and then present a framework based on OVM by 
Pohl et al . 1 1 1 to perform checks for consistency, liveness, 
commonness, realizability (completeness), and flexibility 
(soundness). 

One of the central concepts of the SPL analyses in the 
above-mentioned works is that of a product. It is defined 
through the notion of consistency between a collection 
of features and components and the constraints imposed 
by variability and traceability. In this report, we contend 
that consistency does not model the natural semantics of 
the implementability relation between problem and solution 
spaces correctly. It allows components and features to co- 
exist without any conflict, but it also allows cases where 
the features may not be derivable from the components. 
Hence, the SPLs can be shown to allow products where the 
components are not related to the features in a more intuitive 
notion of traceability. Therefore, we define when a feature 
can be derived from a set of components. Using this, we 
define a product of the SPL by a (specification, architecture) 
pair, where all the features in the specification are derived 
from the components in the architecture. This definition of 
products is tighter than the existing "consistency" based 
definitions. 



Another contribution of the report is a simple yet expres- 
sive, abstract model of a productline where we formally de- 
fine the derivability notion through the traceability relation. 
We then define a set of SPL analysis problems. Some of 
these problems are already addressed in earlier works but 
are redefined in the light of the new concepts. The others 
are new and arose because of the separation of problem 
and solution space linked through traceability. We show that 
these problems, in general, can be encoded as Quantified 
Boolean Formulas(QBF) and QSAT solvers lfTTI can be used 
to solve the problems. We illustrate the methodology on a 
small fragment of a realistic productline. 

The summary of our contributions in this report are the 
following: 

1) A new definition for SPL products based on a notion of 
derivability of feature specifications from component 
architectures. The traceability relation plays the central 
role in this definition. 

2) A simple, abstract semantic model of SPL with trace- 
ability. The model abstracts out the details from the 
existing descriptions of SPL in the literature and 
allows us to define the core concepts in a formal and 
concise manner. 

A set of analysis problems in the SPL, some of which 
are known but cast anew in the light of the new 
definitions, and others that are novel. 
A solution method for the analysis problems which 
is based on QBF encoding and QSAT solving. This 
is necessitated by the nature of some of the analysis 
problems and is in contrast to the SAT based solv- 
ing methods generally employed for the extant SPL 
analyses. 

Outline of The Report: In the following section, we 
introduce a case study of Entry Control Product Line (ECPL) 
from the automotive domain. This is used as a running 
example throughout the rest of the report. The formal model 



3) 



4) 



of an SPL with traceability is described in Section III It 



introduces the central notion of derivability and the analyses 
we would like to carry out in SPL. In Section [V] we 
show how the analysis problems can be encoded in QBF. 
The results of the analyses using QSAT on the ECPL case 



study is presented in Section IV Finally, we conclude in 



Section VIII with a summary of the report and some future 
directions. The proof of the main result relating the analysis 
problems and QBF formulae is given in the appendix. 

II. The Entry Control Product Line (ECPL) 

We introduce a fragment of a typical Entry Control 
Product Line (ECPL) used in the automotive industry. It 
will be used to illustrate the concepts throughout the report 



and as a case study in Section IV The entry control system 
comprises all the features involved in the controlling of door 
locking/unlocking in a car. In this study, we focus on the 
following subset: 



• Manual lock: controls the locking/unlocking through 
manual lever presses 

• Power lock: controls the locking/unlocking according to 
key button press, courtesy switch press and sill button 
press. 

• Door lock: controls automatic locking of doors when 
the vehicle starts. 

• Door relock: controls automatic relocking of doors in 
case of pick up/drop and drive. 

The ECPL feature diagram: Figure [T] presents the 
feature diagram of the ECPL (a la Czarnecki [12]). The dark 
gray boxes are features of the ECPL. The light gray boxes 
are parameters modeled as features. The Power lock feature 
is mandatory. Manual lock is optional. When it is present, 
the Power lock feature is excluded. The Door lock feature is 
optional and can be triggered either when gear is shifted out 
of park or when car speed reaches a predefined value. The 
Door relock feature is optional. The car should have either a 
manual or an automatic transmission. Manual transmission 
disallows the "park options" of Door lock since there is no 
park gear in a manual gearbox. 



Entry control 



Automatic Manual 




Figure 1. The feature diagram of the ECPL. 

The ECPL architectural diagram: Figure [2] represents 
the platform of ECPL using a notation called Modal Ar- 
chitectural Model (abbreviated as MAM). It is a simplified 
form of EASEL by iTOl and yet preserves the essential 
notion of variability central to the product line. The platform 
is composed of three components: Door lock manager, 
Power lock, and Auto lock. The first is mandatory but 
the two others are optional (denoted by dotted boxes). The 
system has seven "in" ports (dark squares) and three "out" 
ports (light squares). The interconnections between external 
and internal ports connect ports of the same type but internal 
interconnection connect complementary ports ("out" port to 
"in" port). The signals "Transmission in Park" and "Speed" 
are alternatives. Similarly "Automatic" and "Manual" inform 
the system on the type of transmission. 

Auto lock component requires two global input signals 
while Power lock component requires five. They provide 
lock/unlock command signals to Door lock manager. The 
command provided by Power lock component depends 
upon manual action, and the command provided by Auto 
lock component is according to the requirements of the 
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Figure 2. The platform of the ECPL. 



features Door lock and Door relock. 

The Door lock manager component arbitrates the 
lock/unlock command signals from Auto lock and Power 
lock and forwards them to the global outputs depending 
upon a calibration (1/Unlock all doors, 2/Unlock Driver 
door, 3/Lock all doors). 

The traceability relations of the ECPL: To avoid con- 
fusion between the homonymous features and components 
(Automatic, Manual, and Speed), we will, in the sequel, 
prefix the labels with /_ or c_ respectively. Table [I] presents 
the required components to implement each feature. 



Feature 


Component 


Power lock 
Door lock 
Door relock 
f_Automatic 
fJVlanual 
Shift out of Park 
f_Speed 


Door lock manager& Power lock 
Auto lock 
Auto lock 
c_Automatic 

c_Manual 
Gear in Park 
cSpeed 



Table I 

Each feature requires component(s) 



Table |H]presents the features provided by the architectural 
elements. 



Component/Interconnection 


Feature 


Door lock manager & Power lock 
c_Automatic 

c_Manual 

Auto lock 
Gear in park 


Power lock 
f_Automatic 
f_Manual 
Door lock & Door relock 
Shift out of park 


c_Speed 


fSpeed 



Table II 

The architectural elements provide some features 



III. Model of SPL : Traceability and 
Implementation 

In this section, we propose a model of the software 
productline making the traceability relation explicit and 
define an implementation relation between architectures and 
specifications based on traceability. 

A. Modeling Decisions 

In (9 1, the traceability relation is given as a set of arbitrary 
propositional constraints over the components and features. 
In the current report, we impose a fairly natural structure 



on the traceability relation, consisting of a provides and a 
requires function for each feature. This is inspired by the 
points of view of the suppliers and integrators (OEMs). 
Suppliers usually would package one or more features in 
a component, which is captured by the provides relation. 
On the other hand, integrators start with a set of features 
which requires a set of components for implementation. 

Importantly, the implementations are related to the specifi- 
cations only when they can be derived using the traceability 
relation. Consider a simple SPL consisting of a feature / and 
a component c, but without any traceability relation between 
/ and c. According to analyses such as in (9), since {/, c} 
is consistent (in a propositional logic), it is considered as a 
product. Clearly, it is not natural. On the other hand, if / 
was provided by c, then {/, c} would be a natural product. 

Another novel point in our model is the notion of ap- 
proximate implementation (Covers). In the literature, the 
definition of implementation is usually exact: we need the 
components that provide exactly the same set of features in 
a specification. However, since many components are pre- 
built by the suppliers, there may not be a choice suitable 
for an exact implementation. For example, if the OEM 
wants a feature of ABS (Anti-lock Braking) and the supplier 
has packaged both ABS and TC(Traction Control) in one 
component, the OEM has to choose this component which 
covers (but does not exactly implement) the specification of 
ABS. 

B. Formal Model 

Let J 7 be a set of features. A subset of T is called a 
specification. The scope of an SPL is a collection of spec- 
ifications: T C p(J r ). The specifications are implemented 
using a set of (reusable) components C. Each subset of C is 
called an architecture. An SPL platform consists of a set of 
architectures: C C p(C)F] 

A traceability relation T connects the features and com- 
ponents: T is specified as a pair (prov,req) where prov 
and req are maps T p(p(C)). Through the traceability 
relation we capture the sufficient (prov(.)) and necessary 
(req(.)) conditions to implement a feature. When prov(f) = 
{C\,C2}, we interpret it as the fact that the set of com- 
ponents C\ (also, G-z) provides the implementation of the 
feature /. On the other hand, when req(f) — {Di, D 2 }, we 
interpret as the fact that the implementation of the feature / 
requires the set of components Di or the set of components 
D 2 . 

Definition 1. An SPL ^ is defined as a triple (F,C,T), 
where T is the scope, C is the platform and T is the 
traceability relation. 

'The representation of specification and platform is semantic in nature. 
Syntactic representation of these may use FODA diagrams, MaMs or a 
variety of notations in the literature. In general, one can have implicit 
representations through constraints on the features and components; we 
will adopt this view in the following sections. 



In the ECPL case study, T contains the nine features of 
Figure [I] and the ECPL scope T contains eight specifica- 
tions. For illustration, we choose the following specifica- 
tions: speci = {Power lock, f_Automatic} and spec2 — 
{Power lock, f _Automatic, Door lock, Shift out of park, 
Doorrelock}. The top-most feature Entry control is in 
every specification and is not mentioned explicitly. 

In ECPL, C contains the three components of Figure [2] 
and the twelve interconnections which are also modeled as 
components. Note that the mandatory interconnections are 
in every architecture and are not mentioned explicitly. The 
ECPL platform C contains nine architectures which can be 
extracted from the ECPL platform. Again, for illustration, 
we select two architectures arch\ = {Door lock manager} 
or archi = {Door lock manager, Power lock, 
c_Automatic, Auto lock, Transmission inpark}. 

The traceability relation in ECPL is given through 
the Tables |ljreg(.)) and |TT|prcw (.)). For example, the 
Auto lock component provides the features Door lock and 
Door r clock. Each of these features requires only Auto lock 
component. 

The main concept of implementability in ^ is defined as 
follows: a feature is implemented by an architecture (set of 
components in C) if the architecture provides the feature 
and simultaneously fulfills the mandatory requirements of 
the feature. 

Definition 2 (Implements). Given an SPL * = (T,C,T), 
implements\f,(C, f) if 3C\ £ prov(f),C2 € req(f)-C2 Q 
dCC. 

The set of features implemented by an architecture C is 
defined as Provided_by^(C) — {f {implement s\^(C, f)}. 

In ECPL, implements^ (spec2, Power lock) holds but 
implements^ (spec±, Power lock) does not hold. More- 
over, if one considers prov as given in Table [II] without 
the last line, implements^ (arch, f_Speed) never holds for 
any architecture arch because prov(f_Speed) ~ even if 
req(f _Speed) = {{c_Speed}}. 

With the basic definitions above, we can now define when 
an architecture exactly implements a specification. 

Definition 3 (Realization). Given C € C and F £ T, 
Realizes(C, F) if F — Provided_by(C). 

Due to the required equality, we have the following easy 
result. 

Proposition 4. An architecture realizes at most one speci- 
fication in an SPL. 

The realizes definition in the above imposes a strictness 
on the implementations. Thus, in the ECPL example, the 
architecture ardi2 realizes the specification spec2, but it 
does not realize spec\ even though it provides the imple- 
mentation of all the features of spec\. In many cases, this 
may be a practical definition. Hence, we relax the definition 



of realization in the following. 

Definition 5 (Covers). Given C € C and F £ T, C covers 
F if Provided_by(C) £ F A F C Provided_by(C). 

The additional condition (Provided_by(C) £ F) is added 
to ensure that the chosen C provides the implementation of 
a specification in the scope. In ECPL, C2 covers T\ but C\ 
does not cover (or even realize) anything. 

Given F, F' e T, let F C F', Then, F' is called the 
extension of F. The following simple proposition establishes 
a connection between the relations realizes and covers. 
Figure [3] depicts these relations pictorially. 





Realizes 








Covers 


c 



Figure 3. Specification F\ extends F2, Architecture C realizes F\ and 
covers F2 

Proposition 6. Given C £ C and F £ T and C covers 
F. Then, there is an extension F' of F in J- such that 
Realizes(C , F'). Hence, if there is no extension of F in 
F, then Realizes(C,F). 

In the ECPL case study, arch2 covers spec%, spec2 
extends spec\, and arch 2 realizes spec2- 

The set of products of the SPL are now defined as 
the specifications and the architectures implementing them 
through the traceability relation. 

Definition 7 (SPL Products). Given an SPL f = 
(J-,C,7~), the products of the SPL denoted as Prod(f&) = 
{(F, C)\Covers{F, C),F £T,C £C} 

In the ECPL, out of 8 specifications and 9 architectures, 
there are 11 products. Even if the architecture arch$ = 
{Door lock manager, Power lock, c_Manual, Auto lock, 
Transmission in park} "covers" the specification 
{Power lock, f_Manual}, this pair is not a product 
because Provided_by(arch 3 ) is not in the scope T. 
This is because arch% provides features f_Manual and 
Shi ft out of park which should be exclusive. 

C. SPL Level Properties 

Given an SPL (F,C,T), we define two important re- 
lationships between the scope (specification space) and 
platform (architecture, or implementation, space). 

1) Completeness: An SPL (F,C,T~) is complete if \/F £ 
T -3C £C -Cover s(C,F). 

The completeness property of the SPL determines if the 
platform for the SPL is adequate to provide implementation 
for all the specifications in its scope. 



The ECPL is complete. For illustration's sake, let us omit 
the last entry in Table [II] Then, none of the specifications 
which include the feature f_Speed is realizable because 
f Speed cannot be derived from any component. 

2) Soundness: An SPL (F,C,T) is sound if VC G C ■ 
3F eT -Cover s(C, F). 

The soundness property relates to the non-redundancy 
of the platform in an SPL. If the architectures (sets of 
components) are generated using certain rules or constraints, 
soundness stipulates that only those architectures which pro- 
vide an implementation of some specification are generated. 

The ECPL is not sound because, for example, the ar- 
chitecture archi does not realize any specification (fea- 
ture set). This is the case with all the architecture where 
Power lock is absent. Now, let us assume that the com- 
ponent Power lock is mandatory. The ECPL is still not 
sound because of arch? only. If arch? is omitted from the 
platform, the remaining ECPL become sound. 

3) Existentially Explicit: Given an SPL, and a specifica- 
tion F G J-, it is called an existentially explicit specification 
in the SPL if there exists a C G C-Realizes(C, F). 

In ECPL, speci and spec2 are existentially explicit. 
However, another specification spec?, = (Power lock, 
f_Automatic, Door lock, Shift out of park) is not, be- 
cause none of the architecture realizes a specification with 
Door lock and without Door relock. 

4) Universally Explicit: Given an SPL, and a specifica- 
tion F G F, it is called a universally explicit specification 
in the SPL if (i) there exists a C G C-Realizes(C, F) and 
(ii) for all C G C-Covers(C, F) =*> Realizes(C, F). 

In ECPL, spec-i is universally explicit. spec\ is exis- 
tentially explicit but not universally explicit because it is 
covered but not realized by the archi- 

It follows from Proposition [6] that 

Proposition 8. If F G T is covered by some architecture 
but is not extendable, then it is universally explicit. If F 
is universally explicit, then none of its extensions has a 
covering architecture. 

In the ECPL, spec^ is covered and cannot be extended; so 
it is universally explicit. On the contrary, if a specification 
has an extension which is covered, the same also covers the 
extended specification. 

5) Unique Implementation: A given specification may 
be implemented by multiple architectures. This may be a 
desirable criterion of the platform from the perspective of 
optimization among various choices. Thus the specifications 
which are implemented by single architectures are to be 
identified. 

F G T has a unique implementation if 3C G 
C-(Covers(C, F) A VC G C-{Covers{C , F) C = C')). 

In ECPL, each specifications including Door relock has 
a unique implementation. On contrary, spec\ has more than 
one implementation. 



6) Common, live and dead elements: Identification of 
common, live and dead elements in an SPL is one of the 
basic analyses identified in the SPL community. We redefine 
these concepts in terms of the our notion of products. 

1) An element e is common if V(F, C) G Prod(^) ■ e G 
FUC. 

2) An element e is live if 3{F, C) G Prod(^)-e G FUC. 

3) An element e is dead if V(F, C) G Prod(^) ■ e 
FUC. 

In ECPL, the feature Manual lock is dead. All the other 
features are live. The component Door lock manager is com- 
mon. 

7) Superfluous Component: A component is superfluous 
if the platform without the component suffices to provide 
the same set of specifications. 

Let P C Prod(^>), spec{P) = {F\(F,C) G P}. Let 
Prod^) = {(F,C)\(F,C) G Prod{^) A (c G" C)}. c is 
Superfluous if spec(Prod(^)) = spec(Prod^ c (^)). 

Superfluousness is relative to a given platform. If in 
an SPL prov(f) = {{a},{b}}, T = {{/}} and 
C = {{a}, {b}}, then both a and b are superfluous w.r.t. vp, 
whereas if either {a} or {b} is removed from the platform, 
the remaining {b} or {a} is not superfluous anymore (w.r.t. 
the reduced SPL). 

Lemma 9. Let c G C be Superfluous for ty. Then, for every 
C G C(c G C (3C G C ■ c # C A Provided _by(C) = 
Provided_by{C')). 

8) Redundant Component: A component is redundant if 
it is not contributing to any feature in any architecture in 
the platform, c G C is redundant if for every C G C(c G 
C {3C G C ■ (c G' C A C C C A Provided_by{C) = 
Provided_by{C')). 

Note that redundancy is a stronger version of superflu- 
ousness; a redundant component is superfluous whereas a 
superfluous element many not be redundant. 

In ECPL, no component is neither superfluous nor re- 
dundant. Let us assume that we have a component called 
Door Relock ah such that {Door Relock ah, Auto lock} 
provides the feature Door Relock. This component would 
be redundant because Auto lock already provides the feature 
Door Relock. 

It is expected that an SPL can be optimized by omitting 
the redundant components without affecting the set of prod- 
ucts. 

Lemma 10. Let c G C be redundant. Construct a SPL 
\f r = (F,F',C) where, T be a traceability relation with 
rea '(f) — rea {f) \ {C\c G C} and prov'(f) = prov(f) \ 
{C\c G C}. Then, Prod(^) = Prod($'). 

9) Critical Component: Given an / G F, a compo- 
nent c is critical for / if for all C G C,(c $ C =>■ 
^implementsq, (C , /)). 



In ECPL, all the components are critical. Let us as- 
sume a component AutolockAit which is an alternative to 
Auto lock and also provides the feature Door lock. In such 
case neither Auto lock or AutolockAit are critical for the 
feature Door lock but Auto lock remains critical for the 
feature Autorelock. 

10) Emerging Features: When a specification 
is not realizable, but is covered by one or more 
architectures, the emerging features Emerging(F) = 
{{C, Provided_by(C) \ F)\Covers{C, F)}. 

Emerging(F) gives the covering architectures and the 
emerging features corresponding to the architecture. 

In ECPL, while considering the only architecture 
that cover (Power lock, Manual, Door lock, f_Speed), 
Door relock will emerge. 

D. Canonical Traceability Relation 

A given traceability relation can be reduced to a canonical 
form without affecting the set of features implementable in 
the SPL. We define the canonical form in the following. 

Definition 11. T is non-redundant if for every feature f, 

1) Ci, Cj £ prov(f),i 7^ j implies Ci % Cj, and 

2) Cj, C., € req(f),i ^ j implies d % Cj. 

Intuitively, if a smaller set of components implements a 
feature, a larger set also will. On the other hand, if a larger 
set of components is required to implement a feature, a 
smaller set is required automatically. Given a traceability 
relation, one can check if it is non-redundant and convert 
it to a non-redundant relation by removing the larger (resp. 
smaller) sets in prov(f) (resp. req(f)). 

Definition 12. T is internally consistent ifWf € P, VC C C, 
(C e prov(f) =* (3C e req(f) ■ C C C)). 

Intuitively, internal consistency of a traceability relation 
states that each set of components in prov(f) can indeed 
satisfy the mandatory requirements (coming from req(f) of 
/• 

Given a traceability relation, we can reduce it to a 
canonical form by the following operations for the prov(.) 
and req(.) of each feature /. 

Claim 13. For a given SPL ^ = (P, C,T), the above 
procedure results in a canonical traceability relation T' 
such that for all C C C, implements^,(C, f) iff 
implements^,' (C, /). 

Proof: The canonization algorithm stops when no rules 
are applicable. Then the conditions of the rules ensure that 
the resulting traceability relation is canonical. 

In order to prove the preservation of implementability, it 
is easy to show that each rule preserves implementability. 

■ 

Theorem 14. If is an SPL with a canonical traceability 
relation, implements^, (C, /) if3C\ <E prov{f)-C\ C C. 



Algorithm 1 Canonization of Traceability Relation 



if prov(f) = or prov(f) is undefined then 

prov(f) <- _L; req(f) <- _L 
end if 

if d, C 3 G prov(f),i ^ j, d C Cj then 

prov(f) <- prov(f) \ {Cj}. 
end if 

if Ci,C 3 e req(f),i ^ j, C, C Cj then 

req(f) <- req(f) \ {Ci}. 
end if 

if C € prov(f), but forallC, € req(f), C t % C then 

prov(f) <- prov(f) \ {C}. 
end if 



Short-Hand 


Feature 


Fi 


Manual Lock 


F 2 


Power Lock 


F 3 


Door Lock 


Fi 


Door Relock 


F 5 


F_autoraatic 


F 6 


Fjmanual 


F 7 


F_speed 


Fs 


Shift out of Park 



Table III 
Features in ECPL. 



Proof: In a canonical traceability relation, due to 
internal consistency, for every C G prov(f),3C" £ 
req(f)-C" C C. Hence the result. ■ 
Since one can always canonize the traceability relation of 
an SPL, henceforth we will assume that the SPL under scope 
is canonical. Thereby, the definition of implementation will 



henceforth be as given in 14 



IV. Analysis of the ECPL 

In this section, we analyze some properties of the ECPL 
example using QuBE. 

In ECPL, there are total 8 Features and 13 Components. 
The features are listed in Table [TIT] and the components are 
given in Table 



IV 



A specification is a subset of Features T. The scope of 
an SPL is a collection of specifications: T C p(J-). In our 
example, scope of ECPL is T = { Si, S2, S3, S4, S5, Sq, 
S7, Ss}- All the specifications are represented in tabular 
form as shown in Table [V] A specification corresponds to a 
column and the l's in the column select the features in the 
specification. 

1) S\ — {Power Lock, F jxutomatic} 

52 = {Power Lock, Fjmanual} 

53 — {Power Lock, F _automatic, Door Lock, 
F_speed} 

S*4 = {Power Lock, Fjmanual, 
F_speed} 



2) 
3) 

4) 



Door Lock, 



Short-Hand 


Component 


Ci 


Door Lock Manager 


C2 


Unlock Driver Door- 


C3 


Unlock all doors 


C4 


Lock all doors 


C5 


Auto Lock 


C6 


Power Lock 


cv 


Courtesy switch 


c 8 


Key signal 


c 9 


Sill door signal 


C10 


C_automatic 


Cn 


Cjmanual 


C12 


Gear in park 


C13 


C_speed 



Table IV 
Components in ECPL. 



5) S5 = {Power Lock, F_automatic, Door Lock, 
Shift out of Park} 

6) Sq = {Power Lock, F_automatic, Door Lock, 
F_speed, Door relock}. 

7) S7 = {Power Lock, Fjmanual, Door Lock, 
F_speed, Door relock}. 

8) S& — {Power Lock, F_automatic, Door Lock, 
Shift out of Park, Door relock}. 

An architecture is a subset of components C. An SPL 
platform consists of a set of architectures: C C p(C). In 
ECPL, the platform is C = {A\, A 2 , A 3 , A4, A 5 , A e , A 7 , 
Ag,, Ag}. The architectures are represented in Table VI 

1) A\ = {Door Lock Manager, Unlock Driver 
Door, Unlock all doors, Lock all doors} 

2) A2 = {Door Lock Manager, Unlock Driver 
Door, Unlock all doors, Lock all doors, Auto 
Lock, C_speed} 

3) A3 = {Door Lock Manager, Unlock Driver 
Door, Unlock all doors, Lock all doors, Auto 
Lock, Gear in park} 

4) A4 = {Door Lock Manager, Unlock Driver 
Door, Unlock all doors, Lock all doors, Power 
Lock, Courtesy switch, Key signal, Sill door 
signal, C ' _automatic} 

5) A§ = {Door Lock Manager, Unlock Driver 
Door, Unlock all doors, Lock all doors, Power 
Lock, Courtesy switch, Key signal, Sill door 
signal, Cjmanual} 

6) Aq = {Door Lock Manager, Unlock Driver 
Door, Unlock all doors, Lock all doors, Auto 
Lock, C_speed, Power Lock, Courtesy switch, 
Key signal, Sill door signal, C_automatic} 

7) A 7 = {Door Lock Manager, Unlock Driver 
Door, Unlock all doors, Lock all doors, Auto 
Lock, C_speed, Power Lock, Courtesy switch, 
Key signal, Sill door signal, Cjmanual} 

8) Ag, = {Door Lock Manager, Unlock Driver 
Door, Unlock all doors, Lock all doors, 
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Table V 

Specifications in tabular form. 
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Table VI 

Architectures in tabular form. 



Auto Lock, Gear in park, Power Lock, 
Courtesy switch, Key signal, Sill door signal, 
C_automatic} 

Ag = {Door Lock Manager, Unlock Driver 
Door, Unlock all doors, Lock all doors, Auto 
Lock, Gear in park, Power Lock, Courtesy 
switch, Key signal, Sill door signal, C jmanual} 
The traceability relations (provides and requires) are as in 
Tables [I] and [TTJ We reproduce the tables here for ease of 
reference. 
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Feature 


Component 


Power lock 


Door lock manager& Power lock 


Door lock 


Auto lock 


Door relock 


Auto lock 


Fautomatic 


C_automatic 


F_manual 


C_manual 


Shift out of Park 


Gear in Park 


F_speed 


C_speed 


Table VII 



Requires relation in ECPL 



e 

of 



Implements:: implements^ (A, f) if 3Ci 
prov(f),C 2 G req{f)-C 2 C C x C A. The set 
features implemented by an architecture A is defined as 
Providedjby^j(A) — {f\implements^(A, /)}. 

Examples : In ECPL, check if implements^^A^, 
Power Lock) holds. 



Component/Interconnection 


Feature 


Door lock manager & Power lock 
C_automatic 
C_manual 
Auto lock 
Gear in park 


Power lock 
F_automatic 
Fmanual 
Door lock & Door relock 
Shift out of park 


C_speed 


F_speed 



Table VIII 
Provides relation in ECPL 
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Table IX 

Feature implementation in given SPL. 



Solution : Let PI = prov(Power Lock). From Table 
[II] PI = prov(P ower Lock) = {{Door Lock Manager, 
Power Lock}}. Let Rl = req(Power Lock). From Table 
[i] Rl = req(Power Lock) = {{Door Lock Manager, 
Power Lock}}. Since R± C Pi C At, implements-^, (A4, 
Power Lock) holds. On other hand R\ C Pi <£. At, 
henceimplementsq,(Ai, Power Lock) does not hold. 

For each feature, we can find the architectures which 
implement it. The results are listed in Table 



IX the l's 



in the column corresponding to an architecture gives us the 
features implemented. 

Realization:: Given A E C and S E F, Realizes(A, 
S) if S = Provided_by(A). 

Example : In ECPL, check if Realizes(A A , Si) holds. 

Solution : The specification Si has the fea- 
tures {Power Lock, F _automatic} . From Table IX 
Provided_by(Ai) = {Power Lock, F _automatic} . Since 
Provided_by(Ai) = Si, Realizes(Ai, Si) holds. On the 
other hand, 

Provided_by(A 5 ) = {Power Lock, F_manual} 7^ St, 
hence Realizes(A^, Si) does not hold. 

The Table [X] shows all the specifications and it's corre- 
sponding realized architectures. 

Covers:: Given A E C and S E F, A covers S if 
ProvidedJby(A) E F A S C Providedjby(A). 

Example : In ECPL, check Covers (A 6 , Si) Hold? 

Solution : The specification Si has {Power 
Lock, F_automatic} features. From Table |IX| 
Provided_by(As) = {Power Lock, Door Lock, 
Door Relock, F_automatic}. Since Provided_by(As) 
E F and Si C Provided_by(A 6 ), hence Covers(A 6 , Si) 
hold. On the other hand, Provided_by(A^) — {Power 
Lock, F_manual} E F but Si ^ Provided_by(A 5 ), 
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Table X 

Specifications and the realizing architectures. 
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Table XI 

Specifications and their covering architectures. 



hence Covers (A5, Si) does not hold. 

Similarly, for all other specifications we can find the 
architectures which cover the specifications. The Table XI 
has all the specifications and their covering architectures. 

A. SPL Level Properties of ECPL 

Completeness:: In ECPL, from Table |XI] one can 
observe that every specification in scope F is covered by 
some architecture in platform C. Hence, ECPL is complete. 

Soundness:: From Table [Xjone can observe that the 
architectures St, S2 and S3 do not cover any specification 
in scope F. Hence, ECPL is not sound. 

Existentially Explicit:: It is observed from Table [X] 
that the architectures Si, S2, Se, Sj and Ss are realized by 
the architectures A4, A5, A$, At and A% respectively. Hence 
these specifications are existentially explicit. From the same 
table, one can observe that the specifications S3, S4 and S5 
are not realized by any architecture in the given platform. 

Universally Explicit:: In ECPL, from Table [X] and 
XI it is observed that the specifications Sg, S7 and S§ are 
realized by the architectures Aq, At and As respectively, and 
these are the only architectures which cover the respective 
specifications. Hence, these specifications are universally 
explicit. As we have already seen from Table [Xj the 
architectures S3, S4 and S5 are not realized at all. The 
remaining architectures Si and S2 are realized by A4 and 
A$ respectively, but Si is also strictly covered (covered but 
not realized) by architectures Aq and At and S2 is strictly 
covered by A 7 . Hence, the specifications Si, S2, S3, S4 and 
S5 are not universally explicit. 



Unique Implementation: : In an SPL, a given specifi- 
cation is said to be uniquely implemented if it is covered 
by exactly one architecture. In ECPL, from Table XI it is 
found that the specifications S3, S4, £5, Sq, Sj and Sg are 
covered by exactly one architecture (A3, Aj, As, A3, Aj, 
A3 respectively). Hence, these specifications have unique 
implementation. On the other hand, the specifications £1 
and S*2 have multiple implementations. 

Products:: In ECPL, from Table [XI] we get 

Prod{^) ={<£!, Ai), (S U A 6 ), (Si, An), (S 2 ,A 5 ), 
(S 2 ,A 7 ), (S 3 ,A 6 ), (S A ,A r ), (S 5 ,A S ), (S 6 ,A 6 ), (S 7 ,A 7 ), 
(S S ,A 8 )}. 

Common, live and dead elements:: From the set of 
products and referring to the tables [V] and [VI] we find that 
the common elements of ECPL are {Power Lock 1 , Door 
Lock Manager, Unlock Driver Door, Unlock all doors, 
Lock all doors, Power Lock 2 , Courtesy switch, Key 
signal, Sill door signal}. Power Lock 1 is the feature and 
Power Lock 2 is the component. 

The live elements for Prod(^) are {Power Lock 1 , Door 
Lock, Door Relock, F _automatic, F_manual, F_speed, 
Shift out of Park , Door Lock Manager, Unlock 
Driver Door, Unlock all doors, Lock all doors, Auto 
Lock, Power Lock 2 , Courtesy switch, Key signal, Sill 
door signal, C _automatic, Cjmanual, Gear in park, 
C_speed}. The only dead element is Manual Lock. 

Superfluous Component:: There are no superfluous 
components in ECPL. For example, consider the element 
AutoLock. The specification Si is covered by architectures 
A4, A3 and As- If architectures A3 and As, which include 
AutoLock, are removed, then Si is still in the product (being 
implemented by A4). However, A3 is the only architecture 
covering S3. Hence, when A3 is removed, (5*3, A3) is re- 
moved from the list of products. This implies that AutoLock 
is not superfluous. 

Redundant Component:: A component is redundant 
if it is not contributing to any feature in any architecture 
in the platform. In ECPL, there are not any redundant 
component. Let us assume we have a component called 
Door Relock Ait such that {Door Relock au, AutoLock 1 } 
provides the feature Door Relock. This component would 
be redundant because Auto lock already provide the feature 
Door Relock. 

Critical Component: : In ECPL, all the components are 
critical. Let us remove the component C_automatic from 
architecture A4. Then, implement sgj(Ai, F _automatic)) 
will not hold. Hence, we can say that the component 
C jxutomatic is critical for feature F_automatic. 

Emerging Features:: In ECPL, the specification S4 is 
not realized by any architecture but it is covered by A 7 . 
So the set of emerging features is Provided_by(A 7 ) — 
S4={Door relock}. 
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Table XII 

Time complexity for Properties and Formulae 



B. Performance 

We have recorded the time required to check the satis- 
fiability of the formulae for some analysis problems using 
QuBE (Refer Table |XIQ , Each formula has been run three 
times and the average time is calculated. The performance 
of QuBE seems quite good for small SPLs the size of ECPL. 

V. Analysis between the specification and the 

IMPLEMENTATION PERSPECTIVES 

In the literature, different analysis problems in SPL are 
usually encoded as propositional satisfiability problems lfl4ll 
and SAT solvers such as Yices, Bddsolve lfT5l etc. are used 
to solve the problems. However, looking at the definition 
of implements and the subsequent problems, we observe 
that there is quantification over the features and components 
which can be encoded as propositions. In fact, we show in 
the following that it is possible to transform the analysis 
problems of the previous section into QBF formula such 
that the questions have an affirmative answer iff the corre- 
sponding QBF formulae hold. 

1) Let C = {ci, . . . ,c n } be the set of all components 
and let T = {fi, . . . , f m } be the set of all features. 
A subset of J 7 is a specification, while a subset 
of C is called an architecture. A platform is a set 
of architectures C C V(C). A scope is a set of 
specifications T C V(F). 

2) Given an architecture C = {ci, . . . , Ck}, let Prop(C) 
be the tuple of propositions 

pr °^ = { :i!\fVfc 

Thus, Prop(C) is an n-tuple made up of O's and 
l's. The tuple Prop(F) for a specification F can be 
defined similarly. 

3) Let / be a feature. Let prov(f) = {Si, S2 ■ ■ ■ , Sk}- 
Each Sj is a set of components that provides /. 
Then we define formula _prov(f) as Vj A Ci es c «- 
f ormulajprov(f) is satisfiable whenever there is 
some set Sj of components that provide feature 
/. If the set prov(f) is undefined(empty), then 
f ormulajprov(f) is FALSE, since there are no com- 
ponents that provide feature /. 



4) Let / be a feature. Let req(f) = {S 1 , S 2 ■ ■ ■ , S k }. 
f requires at least one set Sj of components for its 
implementation. Then, we define formula_req(f) = 
VjAc.eS c »- formula_req(f) is satisfiable iff 
req(f) has at least one set (say Sj) of its required 
components. If req(f) is empty or undefined, then 
formula_req(f) is TRUE, since there are no require- 
ments for /. 

5) Let / be a feature and let prov(f) — {S\ , S 2 ■ ■ ■ , S k }. 
Given a tuple of component parameters ',... ,d n ) 
where each is or 1, and a feature /, we define the 
formula / ^implements', . .. ,d n ,f) as 

n 

Vci . . . c n {[f\' q)] formula jprov(f)} 

i=l 

Whenever the truth values of Cj agree with those of 
the variables of some Sj in prov(f), or correspond 
to a superset of some Sj in prov(f), the formula 
f ormula_prov(f) will hold good. 

6) Let F = {/i, f 2 , ■ ■ ■ , fi} be a specification. For 
each fi, let prov(f t ) = {Su, . . . , S ik } be defined. 
Consider a tuple of component parameters ',..., d n ) 
and a tuple of feature parameters (/{,..., f' m ). 
Here again, each c-,/j is a zero or a 1. Define 
/ .covers', d n , /(,..., /„) as 



=^ / -implements', 



Define fjrealizes', c' n , /(,... , /^) as 

m 

^ f -implements', ...,c' n , fi)) 

i=i 

7) Let * = (J, C, T) be an SPL. Let C = {Si, . . . , S* fc }. 
Given a tuple of component parameters , . . . , <4 
where each is or 1, the predicate Ci', . . . ,c' n ) 
is defined as 

V A 

j CieProp(Sj) 



c' 



Then Ci', . . . , c' n ) is satisfied iff {c' k 



1} 



for some Si G C. Cp (/(, ■ ■ ■ , f' m ) i s defined similarly. 

Lemma 1. (Internal Consistency of Traceability) Consider 
a canonical SPL. Let TCF, the trace consistency formula be 
defined as Vci . . . c„. f\f eF [f_prov(f) => f_req(f)]. Then, 
T is internally consistent iff TCF is true. 

Lemma 2. (Implements) Given a canonical SPL, a set 
of components C, and a feature f, implement s(C ', f) 
iff f -implements', . . . ,c' n , f) where Prop(C) = 
',..., c' n ). 

Lemma 3. (Realizes, Covers) Given a set of components C 
and a set of features F, let Prop(C) — ',... ,c' n ) and 



Prop(F) = (f [,..., f' m ). Then the following statements 
hold: 

1) C covers F iff f_covers', c' n , f [,..., f' m ) 

2) C realizes F iff f_realizes' , ... ,d n ,f[,... , f' m ) 

Lemma 4. (Completeness, Soundness) Given an SPL, the 
SPL is complete iff 

V/{ • • • fL[C F (f{, ■ ■ ■ , f m ) => 3c[ . . . d n [d', . . . , c'J A 
f -covers', ... ,c' n , f[, f' m )] 

Given an SPL, the SPL is sound iff 
Vci . . . c n [d', c fe )] 3/i . . . fj[C F (h, fj) A 
f_covers', ...,c k ,f 1 ,.. .,/,•)] 

Lemma 5. (Existentially Explicit Features) Given a set 
of features F, let Prop(F) = (f f' m ). Then 
F is existentially explicit iff 3d x . . . d n [C]', . . . , c' n ) A 
f realizes',. .., c'„, /{,... , f' m )]. 

Lemma 6. (Universally Explicit Features) Given a set 
of features F, let Prop(F) = (f f' m ). Then F 
is universally explicit iff 3c[ . . .d n [Cj', . . . ,d n ) A 
f realizes',. .., d n , /(,... , f' m )\ A 
^d x ...d n {\(Cj',...' n ) A 
f -covers', d n , /(,... , f' m )] 
fjrealizes',. .., d n , /(,... , f' m )}. 

Lemma 7. (Unique Implementation) Given a set of 
features F, let Prop(F) = (/{,..., f m ). Then F has a 
unique implementation iff 3d 1 . . . d n [Ci', . . . ,d n ) A 
f -covers' , . . . ,d n , f{, . . . , f m )] A 
W[...d' n {[C I (d' 1 ,...,d' n )A 

f_covers(d' 1 , d' n , /{,..., f'J] => (Af =1 (^ & <)} 

Lemma 8. (Common, live and dead elements) 

1) A component c is common iff 

vc[,...,d n ,f {,..., f; n {[Ci',...,d n ) a 

C F {f'i, f' m ) A f -covers', . . . ,d n , f[, . . . , f' m )} ^ 
c} holds. 

2) A component c is live iff 

3d 1 ,...,d n ,f [,..., f m {[d',...,d n ) A 
C F {f[,..., f' m ) A f_covers', ... ,c' n , f f' m ) A 
c} 

3) A component c is dead iff 
W 1 ,...,d n ,f[,...,f^{[C I ',...,d n ) A 
C F {f'i, f' m )Af_covers', . . . ,d n , f[, . . . , f' m )} 
^c} holds. 

Lemma 9. (Superflous) A component Ci is 
superflous iff Vci, <4, /{,... , f' m {[c'i A 

d',...,d n ) A C F {f [,..., f' m ) A 

f -covers', d { , c' n , /(,... , f' m )] 
3d[,...,d' n [^AC I (d[,...,d' n )A 
f_covers(d[,...,d' n ,f[,...,f m )}}. 

Lemma 10. (Redundant) A component Ci is redundant 
iff \fd 1 ,...,dj' 1 ...,f' m {[di A d',...,d n ) A 
C F (fi, ■■■,f m ) A f -covers',..., d n , f f' m )] => 



3d[ . . . <K A (A: =1 A => A 4) A CjK, . . . , <)A 
f_covers(d[,. . . , < l7 /(,..., /,'„)]}. 

Lemma 11. (Critical) A component c is 
critical for fj iff Vci, . . . , c^{[(7/(ci, . . . , c' n ) A 
f implements', . . . , c' n , fj)} c}. 

Lemma 12. (Extends) Let F and F' be subsets of fea- 
tures. Let Prop(F) = (fi,--.,f m ) an d Prop(F') = 
(/(,..., f' m ). Then F' extends F iff A™ x {Ji => ti) * true. 
F> is extendable iff 3 f [,..., f m [f\™=i fi => /■>')]■ 

Theorem 15. Given an SPL ty, each of the properties listed 



in Table XIII holds good iff the corresponding formulae 
evaluate to true. 

Proof: The detailed proof is given in the full version of 
the paper. ■ 

VI. Implementation 

In this section, we give some details of the implementation 
of the theory developed, using off-the-shelf QSAT solvers. 
We also illustrate the encoding of the analysis problems in 
QBF and their solutions through a small example. 

A. QBF and QDIMACS format 

Quantified Boolean Formulae (QBF) are generalized form 
of propositional formulae with quantification (existential and 
universal) over the propositional symbols. The boolean satis- 
fiability problem for propositional formulae is then naturally 
extended to QBF satisfiability problem (QSAT). 

Most QBF solvers follow QDimacs, a standard input 
and output file format. QDimacs Format is built on top 
of the DIMACS standard for SAT Solver. A QDimacs file 
representing a QBF has three parts: Preamble, Prefix and 
Matrix. The notations use a unique indexing of all the 
propositional variables occurring in the QBF. 

1) Preamble : The Preamble contains different types of 
information about the file, namely, 

a) Comments : Each comment line should start 
with lower case character 'c'. There can be 
multiple comment lines in the File. 

Format: 

C COMMENT_STRING 
Example: 

c Testing QBF formulae. 

c qdimac file for completeness. 

b) Problem Line : There is only one problem line 
in each QDimacs File. The problem line starts 
with the lower case character 'p' followed by the 
string 'cnf, which denotes that the given formula 
is in conjunctive normal form (CNF). The 'cnf 
string is followed by variables count and clauses 
count. 

Format: 

p cnf VAR_COUNT CLA_COUNT 



Example: 

p cnf 4 2 

2) Prefix : The Prefix lines are used to represent the 
quantifiers in the Formula. Each Prefix line starts with 
a lower case character 'a' or 'e'; 'a' represents univer- 
sal quantifier and 'e' represents existential quantifier. 
Quantifiers are followed by the indices of variables. 
Each prefix line ends with '0'. 

Example: 
a 1 2 
e 3 4 

3) Matrix : Each line in matrix represents a clause 
and should end with '0'. Each propositional variable 
in clause is represented by it's corresponding unique 
index. The complement of a variable is represented by 
negation of the index. 

Example: 
1 3 
2-4 

As an example, the QDimacs format for the formula 
VX3Y((XV^Y)A(^X\/Y) is as follows. The first line is 
a comment line. The second one is the problem line which 
mentions that there are two variables and two clauses. The 
third line represents the universal quantification of X and 
the fourth line represents the existential quantification of Y . 
The fifth line represents the first clause (X V ->Y) and the 
sixth line represents the second clause (—iX V Y). 

c Illustration 
p cnf 2 2 
a 
e 
1 



-1 



1 

2 

-2 
2 



QuBE is a solver for Quantified Boolean Formulas 
(QBFs). It accepts QBFs in QDimacs format and returns 
TRUE if the formula is satisfiable, and FALSE otherwise. 
We have developed a tool called CNF2QDIMAC converter. 
The tool converts QBFs in CNF to QDimacs format which 
can be given as input to QuBE. Conversion of arbitrary 
QBFs to CNF is done using some online tools. 

B. An Illustrative Example 

Consider the following SPL * = (C, J, T) with C = 
{{ci,c 2 },{c 3 ,c 4 }} and T = / 2 }, {/ 3 }}- Thus, there 
are 4 components and 3 features. Further, let the traceability 
relation T be given as follows: 

. prov(fx) = {{c 1 ,c 2 },{c 3 }},req(f 1 ) = {{{ci},{c 3 }} 
. prov(f 2 ) = {{c 2 \},req(f 1 ) = {{c 2 }} 
. prov(f 3 ) = {{c!,c 4 }},req(f 3 ) = {{c 4 }} 

Let us answer the following questions using the logic 
formulation with the help of the QuBE tool. 
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Formula 


Implements(C, /) 
Prop(C) = (c' 1 ,...,c' n ) 


f _implements(c' 1 , . . . ,c' n , f) 


C covers F, Prop(C) = (c[ , . . . , c' n ) 
C realizes F , Prop(F) = {fa . . . , fa) 
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^ complete 


V/( ■ • ■ fa{C F (f{ , . ..,fa)=> . . . <[C/(ci, . .VJA /_couers(ci, 4, /{,... , fa)]} 


* sound 


V4 . . . e^C/K, . . . , <)] =>3f[... fa[C F (f[,. ..,fa)A f^overs^,. . . , c' k , f lt . . . , fa]} 


F existentially explicit 
Prop(F) = (/(,..., fa) 


=i — J 7 — r ^-y — 7 — 7 7 — ^ : p T~' 7 — J J 7T7 ttj — , i 

34 ...<[C,(c' 1 ,...,c'jA /.recces (4 ,...,<,/(,..., /^)J 


F universally explicit 

Prop(F) = (f fa) 


34 . . . c;[C/(ci, . • ■ , c' n ) A /_reafees(ci, . .., 4, /(,... , A Vci . . . c^KCiM, • . . , c' n )A 
f .covers^, ...,<,/{,..., /^)] => /_reafazes(ci , . ..,<,/;,..., /^)}. 


F has unique implementation 

Prop(F) = (/(,..., fa) 


3 C ; . . . cjc^,. . . , c' n ) a /.co^r^c;, ;,./; /;j]a 

\/t/ it r t /it if \ a i* /if it f*t *»/ \ i / , n /it t \ ~i 

Vd'j . . . <4{ . . . ,<4) A f_covers{d' x , ...,<,/{,..., /^)] => (A™ =1 « c<)} 


c common 


\ / f f rl rf ( X s~i / f f \ a / r/ f 1 / \ . /■ / / f rf (*/ M 1 

Vci, c4, /{,... , /m{[C/(ci, . . . , O A C F (/{ , . • ■ , /m) A /_cot)ers(ci, . . . , fa fa... , fa)] => c} 


c live 


3ci, . . .,c' n ,fa.. .,fa{[Ci(fa. ■ ■ , c' n ) A CH/J, ... ,/^) A /Lowers^, . . . ,<,/(,. . . ,/^) A c} 


c dead 


Vci, 4, /(,... , /UiC/K, . .,<t)A C F (fa. ..,fa)A f^overs^, fa fa..., fa)] => -c} 


Cj superfluous 


Vc' 15 ..., 4, /{,..., A C 7 K <i) A C F (fa...,fa) A }_covers{fa..., fa fa..., fa)] ^ 

3d', , . . . , d' n h< A C T {d\ ,...,<) A f_covers{d\ ,...,<,/{,..., /^)]} 


Cj redundant 


Vci, ■ ■ ■ . </( ■ ■ • . /UK A C/K- • • ■ . <) A C F (/J, . • • , S'm, ) A /_co„er S (ci, . . . ,c' n , fa ...,fa)]^ 
3d\ ...d' n h< A (A™ =1 < => A <) A Cj{d\ , . . . , d' n ) A f_covers(d\ ,...,<,/{,..., fa)]} 


c critical for /j 


Vc 'n • ■ • > c n{[Ci(ci, ■ • ■ , c n ) A f Jmplements^, . . .,cf n ,fj)] => c} 



Table XIII 
Properties and Formulae 



1) Does C = {c\,C2} implement /i? Clearly, 
the answer is YES. In the logic formalism, 
f implements (1, 1,0,0, /i) is defined as 
Vcic 2 c 3 c 4 {[(l ci) A (1 =>• c 2 ) A (0 =4> 
c 3 ) A (0 c 4 )] =4> f_prov(f 1 )} where f_prov(f 1 ) 
= (ci A c 2 ) V c 3 . The formula when simplified is 
Vcic 2 c 3 C4((ci A c 2 ) ((ci A c 2 ) V c 3 ). It is easy to 
see that the formula evaluates to true. Hence QuBE 
returns an affirmative answer. 

Now consider C — {c 3 }. Does C implement / 3 ? 
Clearly, the answer is NO. In the logic formalism, 
f implements (0, 0, 1, 0, / 3 ) is defined as 
Vcic 2 c 3 c 4 {[(0 ci) A (0 ^ c 2 ) A (1 =>• c 3 ) A (0 => 
Ci)] ,f_prov(f 3 )} where f_prov(f 3 ) = (a A c 4 ). 
The simplified formula is Vcic 2 c 3 C4(c 3 (ci A c 4 )). 
The assignment c 3 = 1, c x = evaluates the 
quantifier-free formula to false. Hence QuBE returns 
a negative answer. 

2) Consider C — {ci,c 2 }. Does C realize 
{/17/2}? Clearly, the answer is YES. In the 
logic formalism, f_realizes(l, 1, 0, 0, 1, 1, 0) is 
defined as ([1 f implement s(l, 1, 0, 0, fi)} A 
[1 f_implements(l, 1, 0, 0, / 2 )] A [0 4^ 
f_implements(l, 1, 0, 0, / 3 )] A [0 4=> 
f implement s(l, 1, 0, 0, / 4 )]. 

Now, f implement s(l, 1, 0, 0, /i) is defined 
as Vcic 2 c 3 c 4 {[(l =>• ci) A (1 c 2 ) A (0 
c 3 ) A (0 c 4 )] f_prov(f 1 )} where 

f_prov(fi) is defined as (ci A c 2 ) V c 3 . Clearly, 
f implement s(\, 1, 0, 0, /i) holds. Thus, we have 
[1 <^=> f implement s(l, 1, 0, 0, /i)] is true. Similarly, 
it can be seen that [1 f implement s(l, 1, 0, 0, / 2 )] 



is true. 

Likewise, f implement s(l, 1,0,0, / 3 ) is 

Vcic 2 c 3 c 4 [(l ci) A (1 c 2 ) A (0 

c 3 ) A (0 c 4 )] (ci A c 4 ), which is false. 
Hence, [0 / implement s(l, 1, 0, 0, / 3 )] is true. 

Similarly, /implements (1, 1, 0, 0, / 4 ) is 
Vcic 2 c 3 c 4 {[(l ci) A (1 c 2 ) A (0 

c 3 ) A (0 c 4 )] =>• (c 4 )}, which is false. Hence, 
[0 4=> f implement s(l, 1, 0, 0, / 4 )] is true. Thus, we 
have the answer true from QuBE. 
Now consider the question: does C realize /i? 
Clearly, C covers /i, but realizes {/i,/ 2 }- 
Again, the logic formalism for the same is 
f_realizes(l, 1, 0, 0, 1, 0, 0), which is defined 
as ([1 <^=> f_implements(l, 1,0,0, fi)] A 
[0 f_implements(l, 1,0, 0, f 2 )] A [0 

f_implements(l, 1,0, 0, / 3 )] A [0 ^ 
/ implement s(l, 1, 0, 0, / 4 )]. 

As seen above, clearly, [1 4=> 
f implement s(l, 1, 0, 0, fi)] holds. However, 
we have f_implements(l, 1, 0, 0, / 2 ) is true 
since prow(/ 2 ) = {{c 2 }}. Then, we do not have 
[0 <^=> ,/ 'implement s(l, 1, 0, 0, / 2 )]. Therefore, QuBE 
returns false. 

3) Is the given SPL complete? That is, for every 
F G J 7 , does there exist some C e C such that 
Covers(C, F)l Clearly, the answer is NO since 
there is no C € C covering {/ 3 } e T. The 
formula for this is \/f[fif 3 [C F (f[ , ft, / 3 ) => 
Bci^CgC^C/^i,...,^) A 
f_covers(c' 1 c 4 , /{,..., / 3 )] . This expands 



! 4 



i c 4 



i f: 4 



i 4 



i 4 



! c 4 



out to 

Cf(1,1,1) 34, 444 [(7/ (4,. 

f_covers(c[, ... ,4, 1, 1, 1)] and 

<7 F (i,i,o) => 34,444^/(4,. 

f_covers(c[, . . . , d 4 , 1, 1, 0)] and 

<7 F (i,o,i) => 34,444^/(4,. 

f_covers(c[, . . . , d 4 , 1, 0, 1)] and 

<7 F (o,i,i) => 34,444[C/(4,. 

f_covers(c[, . . . , d 4 , 0, 1, 1)] and 

c F (0,0,1) => 34, 444 [C/ (4,. 

f_covers(c' 1 , . . . ,d 4 ,0, 0, 1)] and 

c F (o,i,o) => 34,444^(4,. 

f_covers(c[, . . . , d 4 , 0, 1, 0)] and 

<7 F (i,o,o) => 34,444[C/(4,. 

f_covers(c[, . . . , 4, 1, 0, 0)] and 

c F (0,0,0) => 34, 444 [C/ (4,. 

f_covers(c[, . . . ,4,0, 0,0)]. 

Among these, C F (1,1,0), C F (0, 0, 1) evaluates to 
true. The rest evaluate to false - hence the formula 
involving them holds. 

Now, consider C F (1,1,0). Then we must 
check whether 344 c 3 c 4[CV( c 'i> • • • > c 4) A 
f_covers(c' 1 , . . . ,d 4 , 1, 1,0)] holds. The tuple 
(1,1,0,0) as well as (0,0,1,1) satisfy 
C/(4, 4, c 3> c 4)- Hence, these are the only 
two tuples that we need to examine for 
(4,4,4,4). Consider (1,1,0,0). Then 
[C/(l, 1, 0, 0) A f_covers(l, 1, 0, 0, 1, 1, 0)] evaluates 
to true A [1 => f ^implements (1, 1, 0, 0, /i)] A [1 =>■ 
/ ^implements (1, 1, 0, 0, /2)]A 
[0 =>■ f_implements(l, 1, 0, 0, /s)]. Clearly, this is 
true, as {ci,c 2 } covers {/i,/ 2 }- 
Now consider C F (0, 0, 1). Then we 
must check 3c[ c' 2 c' 3 d 4 [C/ (4 , • • • , 4) A 
f_covers(c[, ...,4,0, 0, 1)] holds. Again, 
consider the two possibilities for C/(4, c' 2 , 4, 4)- 
Look at (7/(1,1,0,0) first. Then we have to 
check if f_covers(l, 1, 0, 0, 0, 0, 1) is true. 
This is [0 =>■ f implements (1, 1,0,0, /i)] A 
[0 f_implements(l, 1, 0, 0, / 2 )] A [1 

/ ^implements (1, 1, 0, 0, /s)]. Clearly, 
f implements (1,1, 0,0, fs) does not hold since 
prov(fs) = {c\,c 4 } and C4 can be assigned 
in this formula. Now consider the second 
assignment (0,0,1,1). Then again, (7/(0,0,1,1) 
holds. Now check if f_covers(0, 0, 1, 1, 0, 0, 1) 
holds. That is, [0 => f implements (0,0, 1, l,/i)] A 
[0 => f_implements(0, 0,1,1, f 2)} A [1 
f_implements(0, 0,1,1, fa)]. Since prov(f 3 ) = 
{{c\,c 4 }}, f_implements(0, 0,1,1, fs) is false. 
Thus, this does not hold good as well. 
Therefore, for {fy} (equivalently, (7 F (0, 0, 1)), there 
is no (7/(4, 4, c 3, c 4) which realizes {fs}. Hence, 
QuBE returns false. Then, we can conclude that the 



SPL is not complete. 

VII. Results of Analyses on The ECPL 
Case-study 

In this section, we analyze some properties of the ECPL 
example using QUBE. The platform C contains the following 
architectures: 

1) (7i = { Door Lock Manager, Unlock Driver Door, 
Unlock all doors, Lock all doors} 

2) C2 = {Door lock manager, Unlock driver door, 
Unlock all doors, Lock all doors, AutoLock, Speed} 

3) C3 = { Door lock manager, Unlock driver door, 
Unlock all doors, Lock all doors, AutoLock, Gear in 
park } 

4) C4 = { Door lock manager, Unlock driver door, Un- 
lock all doors, Lock all doors, Power Lock, Courtesy 
switch, Key signal, silldoor signal, Automatic} 

5) C 5 = { Door lock manager, Unlock driver door, Un- 
lock all doors, Lock all doors, Power Lock, Courtesy 
switch, Key signal, silldoor signal, Manual} 

6) Cq — { Door lock manager, Unlock driver door, 
Unlock all doors, Lock all doors, AutoLock, Speed, 
Power Lock, Courtesy switch, Key signal, silldoor 
signal, Automatic} 

7) C7 = { Door lock manager, Unlock driver door, 
Unlock all doors, Lock all doors, AutoLock, Speed, 
Power Lock, Courtesy switch, Key signal, silldoor 
signal, Manual} 

8) (7g = {Door lock manager, Unlock driver door, 
Unlock all doors, Lock all doors, AutoLock, Gear 
in park, Power Lock, Courtesy switch, Key signal, 
silldoor signal, Automatic} 

9) Cg — { Door lock manager, Unlock driver door, 
Unlock all doors, Lock all doors, AutoLock, Gear 
in park, Power Lock, Courtesy switch, Key signal, 
silldoor signal, Manual} 

Consider the following specifications in the scope T . 

1) F\ = {Power Lock, f_automatic} 

2) F 2 = {Power Lock, f_automatic, Door Lock, Shift 
outof Park, Door re lock}. 

1) Does (7i realize Fi? The formula to check is [1 
f implement s(l, 1, 1, 1,0, . . . , O.PowerLock)] A [1 
/ implement s(l , 1,1,1,0,..., 0, f_automatic)] 
A... [0 f implement s(l, 1, 1, 1, 0, . . . , O.Door 
relock)] 

Lets look at / implement s(l, 1,1,1,0,..., 0,PowerLock). 
Let Ci = Door Lock Manager, c 2 = 
UnLockDriverDoor, C3 = Unlockalldoors, 
c 4 = Lockalldoors, c 5 = PowerLock. This is 
defined as Vci, . . . , c„{([l Ci] A [1 c 2 ] A [1 
c 3 ] A [1 c 4 ] A [0 c 5 ; j . . . [0 c„]) (ci A c 5 )}. 
Clearly, this does not hold (for c 5 = 0, the formula 
does not hold). 



Hence, QUBE returns false. 

2) Is ECPL sound? If so, then for every Ci € C, we can 
find a specification Fj such that Covers(Ci, Fi). The 
formulae for this is 

Vc 1 ...c n [C I (cx,...,c n )] => 

3.h...f m [C F (h,...J m )A 
f_covers(d, . . . , c„, fx, . . . , f m )] 

Consider the tuple (1, 1,1,1,0,..., 0) where the first 
four entries are 1, and the rest are zero. This cor- 
responds to C\. Clearly, (7/(1, 1,1,1,0,..., 0). Lets 
look at f_covers(l, 1, 1, 1, 0, . . . , 0, /{, . . . , f m ). It is 
easy to see that f_implements(l, 1,1,1,0,..., 0, /) 
does not hold good for any / since c\ = 
DoorLockManager does not provide any features 
alone, and Cj, i > do not provide any features. Thus, 
the formula does not hold good, and QUBE returns 
false. Hence, the ECPL is not sound. 

3) Is F\ universally explicit? If so, then any d € C 
which covers Fx must realize F\ ; moreover, there must 
be atleast one C £ C which covers it. The formula for 
this is 

3cf 1 ...c/ n [C I (cf 1 ,...,c/ n ) A 
f_realizes(c' x , ... ,c' n) /(,... , f' m )] A 
Vc' 1 ...cU[(C / ( C ' 1 ,...,4) A 
f_covers{c' x , . . . , d n , f' m )] 
f _realizes{c' x , c' n , /{,... , /,'„)}. 
Let us denote ci=Door lock manager, C2=AutoLock, 
C3=Power Lock, C4=Gear in Park and C5=Automatic, 
C6=Unlock driver door, C7=Unlock all doors, cs=Lock 
all doors, cg=Courtsey switch, cio=Key signal, cn=sill 
door signal, ci2=Speed and ci3=Manual. Similarly, 
let /i=Power Lock and / 2 =f_automatic. Consider the 
component tuple (1, 0, 1, 0, 1, 1, 1, 1, 1, 1, 1, 0, 0). 

Then we have C*/(l, 0, 1, 0, 1, 1, 1, 1, 1, 1, 1, 0, 0).(C 4 
corresponds to this set) and 

f_realizes(l, 0, 1, 0, 1, 1, 1, 1, 1, 1, 1, 0, 0, 1, 1, 0, ... , 0) 
(C4 realizes Fx). Corresponding to this tuple, Consider 
the component tuple (1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 0, 0). 
Clearly, C/((l, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 0, 0) (C 8 corre- 
sponds to this). As C4 C Cs, Cs covers Fx. However, 
f_realizes(l, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 0, 0, 1, 1, 0, ... , 0) 
does not hold since : 

Consider 

f_implements((l, 1, 1, 1, 1, 1, 1, 
1, 1, 1, 1, 0, 0, Shi ftoutof Park), 
a conjunct in 

f_realizes(l, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 0, 0, 1, 1, 0, ... , 0). 
Now, it can be seen that 
/ ^implements ((1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 0, 0, 
Shiftout of Park) holds, since the component Gear 
in Park provides the feature Shift out of Park. 



Hence, this conjunct does not hold good. Hence, 

f_realizes(l, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 0, 0, 1, 1, 0, ... , 0) 
does not hold. 

Hence, QUBE returns false. Thus, for the component 
tuple (1,0,1,0,1,1,1,1,1,1,1,0,0) which realizes 
Fx, there exists a component tuple which covers, but 
does not realize Fx. Hence, Fx is not universally 
explicit. 

VIII. Conclusion 

In this report, we have given a new definition for products 
in a Software Product Line, based on the notion of derivabil- 
ity of feature specifications from component architectures. 
The traceability relation between features and components 
plays a central role in this definition. We show that our 
definition is different from the consistency based definition 
of SPL products and captures the implementation relation 
in a more natural way. In the light of this, we define a 
set of analysis problems for the SPLs. We show that these 
problems can be formulated as Quantified Boolean Formulae 
and can be solved using QSAT tools such as QUBE. 

We have demonstrated the feasibility of our approach 
through a small fragment of an industrial SPL. The scal- 
ability of the above approach for complete SPLs is yet to be 
studied. Since QSAT problem is PSPACE-complete, generic 
QSAT solvers may not scale well. However, one observes 
that the formulas for the analyses have very specific structure 
which can be exploited for efficient QSAT solving. 

The proposed semantic model of the SPL treats specifi- 
cations and architectures as sets of features and components 
respectively. When richer structure is imposed on these 
elements, it will affect the definition of traceability relation. 
Then the implementation relation has to be refined to handle 
the resulting complexity. 
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